chore: enforce awaiting promises by lint - #2863

Please address the comments from this code review:

## Overall Comments
- The async `accessGroupServiceFactory.useFactory` now awaits a dynamic import without any error handling; consider wrapping the import and service construction in a try/catch so misconfigured `responseProcessorSrc` doesn’t break module initialization silently.
- In `datasets.module.ts`, `await policyService.addDefaultPolicy(...)` assumes the surrounding context is async; double-check that the enclosing function is marked `async` or otherwise explicitly handles the returned promise to avoid runtime/TypeScript issues.

## Individual Comments

### Comment 1
<location path="src/opensearch/opensearch.service.ts" line_range="76-81" />
<code_context>

   onModuleInit() {
-    this.initWithRetry();
+    this.initWithRetry().catch((error) => {
+      Logger.error(
+        "Opensearch initialization failed unexpectedly",
+        error,
+        "Opensearch",
+      );
+    });
   }
</code_context>
<issue_to_address>
**question (bug_risk):** Catching initialization errors here prevents module init from failing; verify this aligns with desired failure semantics and health reporting.

Because the error is only logged, `onModuleInit` succeeds even when Opensearch is down, so the service can start with a broken search subsystem. If Opensearch is required for correct operation, consider rethrowing after logging or wiring this failure into your readiness/health checks so the service is marked not-ready when initialization fails.
</issue_to_address>

### Comment 2
<location path="eslint.config.mjs" line_range="58-59" />
<code_context>

       "@typescript-eslint/no-explicit-any": "error",
       "@typescript-eslint/no-inferrable-types": "error",
+      "@typescript-eslint/no-floating-promises": "error",
+      "@typescript-eslint/no-misused-promises": "error",

       quotes: [
</code_context>
<issue_to_address>
**suggestion:** Enabling strict promise rules globally can cause friction in framework callbacks; consider scoping or adding targeted overrides.

In Nest/Express there are common patterns (event handlers, middleware, lifecycle hooks) where async functions or returned promises are expected and harmless. Please check whether these rules create noisy violations in those areas and, if so, consider scoping them (per folder/file) so you keep the safety benefits without fighting the framework’s patterns.

Suggested implementation:

```javascript
      "@typescript-eslint/no-explicit-any": "error",
      "@typescript-eslint/no-inferrable-types": "error",
      // Promise rules are warnings by default to avoid friction in framework callbacks;
      // stricter enforcement is applied via targeted overrides.
      "@typescript-eslint/no-floating-promises": "warn",
      "@typescript-eslint/no-misused-promises": "warn",

      quotes: [
        "error",

```

To fully implement the scoping behavior you described, add or extend an `overrides` section in `eslint.config.mjs` such as:

- For general app code (e.g. `src/**/*.ts`, excluding framework-specific folders):
  - Set `@typescript-eslint/no-floating-promises` and `@typescript-eslint/no-misused-promises` back to `"error"`.

- For framework-heavy areas (adjust paths to match your project layout, examples):
  - `src/**/middleware/**/*.ts`
  - `src/**/interceptors/**/*.ts`
  - `src/**/guards/**/*.ts`
  - `src/**/filters/**/*.ts`
  - `src/**/listeners/**/*.ts`
  - `src/**/subscribers/**/*.ts`
  - `src/**/events/**/*.ts`
  In those overrides, either:
  - Keep these rules at `"warn"`, or
  - Configure them more leniently (e.g. `@typescript-eslint/no-misused-promises` with `checksVoidReturn: false` for callbacks).

You’ll need to tailor the `files` globs in `overrides` to your actual Nest/Express folder structure to ensure that normal request-handling/business logic gets strict promise checks, while middleware and lifecycle hooks avoid noisy, low-value violations.
</issue_to_address>